denoについて「Node.jsにおける設計ミス by Rian Dahl」から半年で変わっていること
僕がdenoを知ったきっかけはNode.js日本ユーザ会代表のFurukawaさんのブログの記事でしたkeroxp.icon ちなみに原題は「10 Things I regret about Node.js」
去年のJSConfでのRian Dahl氏の公演の日本語訳として多くの人が読んだと思います
ここで記述されている（正確にはRy氏が語っている）denoについてのことと半年後の今（2019/1/7）ではいろいろと内容が異なっているので違いをまとめてみます
自分もdenoのコアコミッタというわけでもないのであしからず
以下、上記のFurukawaさんのブログ記事の引用を含みます
2019/1/7現在の話です
開発状況について
最初に言っておくと、全然まだまだプロトタイプレベルです。 動かないのが普通の状況なので、 lldb でデバッグして直したりしない限り動かないし、ましてやこれでなにか作るのは強くオススメしません。
keroxp.icon
プロトタイプレベルかもしれませんが、普通に動きます
ベータながら安定版がリリースされており、masterのCIも大抵の場合通ってます
現在の最新版はv0.2.5
mac/linuxでは普通に動くはず
ただ何かを作るのは今でも強くオススメしません
足りない機能が多すぎるので
TLSとかもまだ開けないです
privilledgeについて
deno は sandbox モデルになっています。デフォルトではネットワークアクセスもなければファイルの書き込み権限もありません。 （--allow-net --allow-writeをつけない限りはネットワークアクセスと書き込み権限が付きません。）
keroxp.icon
変わっていません
一方で、--allow-readオプションの追加が現在議論されています
理由は、デフォルトでファイルreadできても--allow-netしない限り問題ないよねという思想があるのですが、だったら--allow-env（環境変数へのアクセス）はいらないよね。どっちにしよう？というのが議論の流れです。
結果--allow-readは追加される方向になりそうです
native code実行について
また、 deno では「ダイレクトに任意のnative codeを実行すること」は許可していません。全ては protobuf の呼び出しによって間接的に実行されます
keroxp.icon
変わっていません。でも多分どこかで何らかの形で必要になってくると思います。SQLiteクライアントとか。
wasmをURL経由でdynamic importして実行とかになるのかな。
--allow-wasmとか増えたりして
「間接的に実行される」というのはdenoはコアの中のTSとRustの間がRPCで行われているということですね
TS<->RustでRPCのメッセージに使うフレームワークはFlatBuffersになっています
モジュールシステムについて
Nodeの既存モジュールとの親和性は求めてません。
importは相対パスか絶対パス、もしくはURLだけでしか指定できません。
keroxp.icon
変わっていません
一方でdenoのコアTSフロントエンドだけはimport * as deno from "deno"というスタイルで読み込めます
これはいつか変わるんだろうか？
JSとの互換性について
通常のJavaScriptも使えるようになります（TypeScriptはJavaScriptのスーパーセットなのでそこまで難しくはありませんが）。
keroxp.icon
これは…なんとも言えません。何を持って通常と言えるのかどうか。
denoにおけるJSの存在は今なんとも言えない感じになっていて、一応importできるはずです
でもdenoで動くJSと動かないJSはたくさんあります
WHATWGのPure JSなら多分今も今後も動くはずです
denoはGlobalコンテキストについてブラウザベースのAPIに追随する方針をとっているので、むしろいまブラウザでしか動かないJSは将来的にはdenoで動くようになるかも
一方で、CommonJSスタイルのモジュールで書かれたJS（require, exports）は読み込めません
denoにはrequireもexportもなく、TSModuleしか使えません
現在はTSがコンパイルされたあとにAMDスタイルのモジュールにトランスパイルされて実行されていましたが、今変わりつつあります
Before: JS and TS both were sent through the typescript compiler where their imports were parsed and handled. Both compiled to AMD JS and finally sent to V8
Now: JS is sent directly into V8. TS is sent through the typescript compiler, but tsc generates ES modules now instead of AMD. This generated JS is then dumped into V8.
このリファクタリングの真意は自分はよくわかってません
2018年だから〜について
Nodeのモジュールをコンパイルするのに Parcel をバンドルツールに使っています。Nodeで行っている事よりも最大限にシンプルです。
keroxp.icon
denoコアのtsフロントエンドのバンドラーのことですね
parcelはもう使っていません。そのかわりrollupを使っているようです もう2019年だからね。仕方ないね。
また現時点ではJS以外のパートは Go を使っています。しかし、これはGoですべてやるという事でもありません。今は色々調査しています。 Rust や C++ も良いでしょう
keroxp.icon
現在denoのコアはすべてRustで書かれています。理由はよくわかっていませんが、V8とGoのGCが独立して動くことをパフォーマンス上の懸念として変わったようです
libdenoというdenoとV8を橋渡しする部分はいくつかのC++ファイルで書かれています
キャッチされない例外がPromiseで起きたら即座にシャットダウンします。
keroxp.icon
多分そう
top-level await をサポートします。
keroxp.icon
まだサポートされていません
機能的に重なる場合はブラウザとの互換を取ります。
keroxp.icon
この方針でコアの実装が進んでいます
hr.icon
細かい部分は相当変わってますね。コアの思想は変わらず実装が進んでいるので期待しても大丈夫だと思います。